1. Field of the Invention
The present application relates to wireless networking and, in some preferred embodiments, to systems and methods for . . . .
2. General Background Discussion
Networks and Internet Protocol:
There are many types of computer networks, with the Internet having the most notoriety. The Internet is a worldwide network of computer networks. Today, the Internet is a public and self-sustaining network that is available to many millions of users. The Internet uses a set of communication protocols called TCP/IP (i.e., Transmission Control Protocol/Internet Protocol) to connect hosts. The Internet has a communications infrastructure known as the Internet backbone. Access to the Internet backbone is largely controlled by Internet Service Providers (ISPs) that resell access to corporations and individuals.
With respect to IP (Internet Protocol), this is a protocol by which data can be sent from one device (e.g., a phone, a PDA [Personal Digital Assistant], a computer, etc.) to another device on a network. There are a variety of versions of IP today, including, e.g., IPv4, IPv6, etc. Each host device on the network has at least one IP address that is its own unique identifier.
IP is a connectionless protocol. The connection between end points during a communication is not continuous. When a user sends or receives data or messages, the data or messages are divided into components known as packets. Every packet is treated as an independent unit of data.
In order to standardize the transmission between points over the Internet or the like networks, an OS (Open Systems Interconnection) model was established. The OSI model separates the communications processes between two points in a network into seven stacked layers, with each layer adding its own set of functions. Each device handles a message so that there is a downward flow through each layer at a sending end point and an upward flow through the layers at a receiving end point. The programming and/or hardware that provides the seven layers of function is typically a combination of device operating systems, application software, TCP/IP and/or other transport and network protocols, and other software and hardware.
Typically, the top four layers are used when a message passes from or to a user and the bottom three layers are used when a message passes through a device (e.g., an IP host device). An IP host is any device on the network that is capable of transmitting and receiving IP packets, such as a server, a router or a workstation. Messages destined for some other host are not passed up to the upper layers but are forwarded to the other host In the OSI and other similar models, IP is in Layer-S, the network layer.
Wireless Networks:
Wireless networks can incorporate a variety of types of mobile devices, such as: e.g., cellular and wireless telephones, PCs (personal computers), laptop computers, wearable computers, cordless phones, pagers, headsets, printers, PDAs, etc. For example, mobile devices may include digital systems to secure fast wireless transmissions of voice and/or data. Typical mobile devices include some or all of the following components: a transceiver (i.e., a transmitter and a receiver, including, e.g., a single chip transceiver with an integrated transmitter, receiver and, if desired, other functions), an antenna; a processor, one or more audio transducers (for example, a speaker or a microphone as in devices for audio communications), electromagnetic data storage (such as, e.g., ROM, RAM, digital data storage, etc., such as in devices where data processing is provided), memory, flash memory, a full chip set or integrated circuit; interfaces (such as, e.g., USB, CODEC, UART, PCM, etc.)- and/or the like.
Wireless LANs (WLANS) in which a mobile user can connect to a local area network (LAN) through a wireless connection may be employed for wireless communications. Wireless communications can include, e.g. communications that propagate via electromagnetic waves, such as light, infrared, radio, microwave. There are a variety of WLAN standards that currently exist, such as, e.g., Bluetooth, IEEE 802.11, and HomeRF.
By way of example, Bluetooth products may be used to provide links between mobile computers, mobile phones, portable handheld devices, personal digital assistants (PDAs), and other mobile devices and connectivity to the Internet. Bluetooth is a computing and telecommunications industry specification that details how mobile devices can easily interconnect with each other and with non-mobile devices using a short-range wireless connection. Bluetooth creates a digital wireless protocol to address end-user problems arising from the proliferation of various mobile devices that need to keep data synchronized and consistent from one device to another, thereby allowing equipment from different vendors to work seamlessly together. Bluetooth devices may be named according to a common naming concept. For example, a Bluetooth device may possess a Bluetooth Device Name (BDN) or a name associated with a unique Bluetooth Device Address (BDA). Bluetooth devices may also participate in an Internet Protocol (IP) network. If a Bluetooth device functions on an IP network, it may be provided with an IP address and an IP (network) name. Thus, a Bluetooth Device configured to participate on an IP network may contain, e.g., a BDN, a BDA, an IP address and an IP name. The term “IP name” refers to a name corresponding to an IP address of an interface.
An IEEE standard, IEEE 802.11, specifies technologies for wireless LANs and devices. Using 802.11, wireless networking may be accomplished with each single base station supporting several devices. In some examples, devices may come pre-equipped with wireless hardware or a user may install a separate piece of hardware, such as a card, that may include an antenna. By way of example, devices used in 802.11 typically include three notable elements, whether or not the device is an access point (AP), a mobile station (STA), a bridge, a PCMCIA card or another device: a radio transceiver, an antenna; and a MAC (Media Access Control) layer that controls packet flow between points in a network.
In addition, Multiple Interface Devices (MIDs) may be utilized in some wireless networks. MIDs may contain two independent network interfaces, such as a Bluetooth interface and an 802.11 interface, thus allowing the MID to participate on two separate networks as well as to interface with Bluetooth devices. The MID may have an IP address and a common IP (network) name associated with the IP address.
Wireless network devices may include, but are not limited to Bluetooth devices, Multiple Interface Devices (M IDs), 802.11x devices (IEEE 802.11 devices including, e.g., 802.11a, 802.11b and 802.11g devices), HomeRF (Home Radio Frequency) devices, Wi-Fi (Wireless Fidelity) devices, GPRS (General Packet Radio Service) devices, 3G cellular devices, 2.50 cellular devices, GSM (Global System for Mobile Communications) devices, EDGE (Enhanced Data for GSM Evolution) devices, TDMA type (Time Division Multiple Access) devices, or CDMA type (Code Division Multiple Access) devices, including CDMA2000. Each network device may contain addresses of varying types including but not limited to an IP address, a Bluetooth Device Address, a Bluetooth Common Name, a Bluetooth IP address, a Bluetooth IP Common Name, an 802.11 IP Address, an 802.11 IP common Name, or an IEEE MAC address.
Wireless networks can also involve methods and protocols found in, e.g., Mobile IP (Internet Protocol) systems, in PS systems, and in other mobile network systems. With respect to Mobile IP, this involves a standard communications protocol created by the Internet Engineering Task Force (IETF). With Mobile IP, mobile device users can move across networks while maintaining their IP Address assigned once. See Request for Comments (RFC) 3344. NB: RFCs are formal documents of the Internet Engineering Task Force (IETF). Mobile IP enhances Internet Protocol (IP) and adds means to forward Internet traffic to mobile devices when connecting outside their home network. Mobile IP assigns each mobile node a home address on its home network and a care-of-address (CoA) that identifies the current location of the device within a network and its subnets. When a device is moved to a different network, it receives a new care-of address. A mobility agent on the home network can associate each home address with its care-of address. The mobile node can send the home agent a binding update each time it changes its care-of address using, e.g., Internet Control Message Protocol (ICMP).
In basic IP routing (i.e. outside mobile IP), typically, routing mechanisms rely on the assumptions that each network node always has a constant attachment point to, e.g., the Internet and that each node's IP address identifies the network link it is attached to. In this document, the terminology “node” includes a connection point, which can include, e.g., a redistribution point or an end point for data transmissions, and which can recognize, process and/or forward communications to other nodes. For example, Internet routers can look at, e.g., an IP address prefix or the like identifying a device's network. Then, at a network level: routers can look at: e.g., a set of bits identifying a particular subnet. Then, at a subnet level, routers can look at, e.g., a set of bits identifying a particular device. With typical mobile IP communications, if a user disconnects a mobile device from, e.g., the Internet and tries to reconnect it at a new subnet, then the device has to be reconfigured with a new IP address, a proper netmask and a default router. Otherwise, routing protocols would not be able to deliver the packets properly.
Media-Independent Pre-Authentication:
Media-independent Pre-Authentication (MPA) is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol. With MPA, a mobile node is not only able to securely obtain an IP address and other configuration parameters for a Candidate Target Network (CTN), but is also able to send and receive IP packets using the obtained IP address before it actually attaches to the CTN. This makes it possible for the mobile node to complete the binding update of any mobility management protocol and use the new Care of Address (CoA) before performing a handover at link-layer.
MPA works over any link-layer and with any mobility management protocol including Mobile IPv4, Mobile IPv6, MOBIKE, HIP, SIP mobility, etc. In MPA, the notion of IEEE 802.111 pre-authentication is extended to work at a higher layer, incorporating additional mechanisms to perform early acquisition of IP address from a network from which the mobile terminal may move, as well as pro-active handover to the network while the mobile terminal is still attached to the current network.
A Mobile Node (MN) supporting MPA, starts a pre-authentication process with an Authentication Agent (AA). A successful authentication enables the PANA authentication agent (PAA) to establish security associations with the AA. This is in addition to a Configuration Agent (CA) used for securely executing a configuration protocol to securely deliver an IP address and other configuration parameters to the mobile nodes, and an Access Router (AR) securely executing a tunnel management protocol to establish a proactive handover tunnel to the mobile node. This entire process is carried out when MN is connected to a current point of attachment. It is explained in detail in “draft-hba-mobopts-mpa-framework-02.txt”, March 2006, and “draft-ohba-mobopts-mpa-framework-03.txt”, Oct. 22, 2006, the disclosures of which are incorporated herein by reference.
Providing secure network access service requires access control based on the authentication and authorization of the clients and the access networks. Client-to-network authentication provides parameters that are needed to police the traffic flow through the enforcement points. A protocol is needed to carry authentication methods between the client and the access network.
PANA provides a link-layer agnostic transport for network access authentication methods. The Extensible Authentication Protocol (EAP) [discussed further below] provides such authentication methods. In this regard, PANA carries EAP which can carry various authentication methods. By the virtue of enabling transport of EAP above IP, any authentication method that can be carried as an EAP method is made available to PANA and hence to any link-layer technology.
The PANA protocol [I-D.ietf-pana-pana] carries EAP messages between a PaC (PANA Client) and a PAA (PANA Authentication Agent) in the access network. If the PaC is a mobile device and is capable of moving one access network to another while running its applications, it is critical for the PaC to perform a handover seamlessly without degrading the performance of the applications during the handover period. When the handover requires the PaC to establish a PANA session with the PAA in the new access network, the signaling to establish the PANA session should be completed as fast as possible.
The PANA protocol is run between a client (PaC) and a server (PAM) in order to perform authentication and authorization for the network access service. The protocol messaging involves of a series of request and responses, some of which may be initiated by either end. Each message can carry zero or more AVPs within the payload. The main payload of PANA is EAP which performs authentication. PANA helps the PaC and PAA establish an EAP session.
For further background information see Protocol for Carrying Authentication for Network Access (PANA), Internet Draft of the PANA Working Group of the I.E.T.F., document no. draft-ietf-pana-pana-12, dated Aug. 24, 2006, to D. Forsberg, Y. Ohba, et al., the entire disclosure of which is incorporated herein by reference as though recited herein in full.
EAP:
Referring to reference to Aboba, RFC 3748 (cited herein-below), illustrative aspects of Extensible Authentication Protocol (EAP) is set forth. EAP is an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission: but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself, however, individual EAP methods may support this.
EAP may be used on dedicated links, as well as switched circuits, and wired as well as wireless links. To date, EAP has been implemented with hosts and routers that connect via switched circuits or dial-up times using PPP [RFC1661]. It has also been implemented with switches and access points using IEEE 802 [IEEE-802]. EAP encapsulation on IEEE 802 wired media is described in [IEEE-802.1X], and encapsulation on IEEE wireless LANs in [IEEE-802.11].
One of the advantages of the EAP architecture is its flexibility. EAP is used to select a specific authentication mechanism, typically after the authenticator requests more information in order to determine the specific authentication method to be used. Rather than requiring the authenticator to be updated to support each new authentication method, EAP permits the use of a backend authentication server, which may implement some or all authentication methods, with the authenticator acting as a pass-through for some or all methods and peers.
Within this latter cited document, authenticator requirements apply regardless of whether the authenticator is operating as a pass-through or not. Where the requirement is meant to apply to either the authenticator or backend authentication server, depending on where the EAP authentication is terminated, the term “EAP server” has been used.
EAP was designed for use in network access authentication, where IP layer connectivity may not be available. EAP is a lock-step protocol which only supports a single packet in flight. As a result, EAP cannot efficiently transport bulk data, unlike transport protocols such as TCP or SCTP.
While EAP provides support for retransmission, it assumes ordering guarantees provided by the lower layer, so out of order reception is not supported. Since EAP does not support fragmentation and reassembly, EAP authentication methods generating payloads larger than the minimum EAP MTU need to provide fragmentation support.
While authentication methods such as EAP-TLS provide support for fragmentation and reassembly, the EAP methods defined in this latter cited document do not. As a result, if the EAP packet size exceeds the EAP MTU of the link, these methods will encounter difficulties.
EAP authentication is initiated by the server (authenticator), whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) in order to run over EAP.
Where certificate-based authentication is supported, the number of additional roundtrips may be much larger due to fragmentation of certificate chains. In general, a fragmented EAP packet will require as many round-trips to send as there are fragments. For example, a certificate chain 14960 octets in size would require ten round-trips to send with a 1496 octet EAP MTU. Where EAP runs over a lower layer in which significant packet loss is experienced, or where the connection between the authenticator and authentication server experiences significant packet loss, EAP methods requiring many roundtrips can experience difficulties. In these situations, use of EAP methods with fewer roundtrips is advisable.
The EAP authentication exchange proceeds as follows:
[1] The authenticator sends a Request to authenticate the peer. The Request has a Type field to indicate what is being requested. Examples of Request Types include Identity, MD5-challenge, etc. The MD5-challenge Type corresponds closely to the CHAP authentication protocol [see: RFC 1994]. Typically, the authenticator will send an initial Identity Request; however, an initial Identity Request is not required, and can be bypassed. For example, the identity may not be required where it is determined by the port to which the peer has connected (leased lines, dedicated switch or dial-up ports), or where the identity is obtained in another fashion (via calling station identity or MAC address, in the Name field of the MD5-Challenge Response, etc.).
[2] The peer sends a Response packet in reply to a valid Request. As with the Request packet, the Response packet contains a Type field, which corresponds to the Type field of the Request.
[3] The authenticator sends an additional Request packet, and the peer replies with a Response. The sequence of Requests and Responses continues as long as needed. EAP is a ‘lock step’ protocol, so that other than the initial Request, a new Request cannot be sent prior to receiving a valid Response. The authenticator is responsible for retransmitting requests. After a suitable number of retransmissions, the authenticator should end the EAP conversation. The authenticator needs to not send a Success or Failure packet when retransmitting or when it fails to get a response from the peer.
[4] The conversation continues until the authenticator cannot authenticate the peer (unacceptable Responses to one or more Requests), in which case the authenticator implementation needs to transmit an EAP Failure (Code 4). Alternatively, the authentication conversation can continue until the authenticator determines that successful authentication has occurred, in which case the authenticator needs to transmit an EAP Success (Code 3). Id.
Among other advantages, the EAP protocol can support multiple authentication mechanisms without having to pre-negotiate a particular one. In addition, Network Access Server (NAS) devices (e.g., a switch or access point) do not have to understand each authentication method and may act as a pass-through agent for a backend authentication server. Support for pass-through is optional. An authenticator may authenticate local peers, while at the same time acting as a pass-through for non-local peers and authentication methods it does not implement locally. Additionally, separation of the authenticator from the backend authentication server simplifies credentials management and policy decision making.
Conceptually, EAP implementations consist of the following components,
[a] Lower layer. The lower layer is responsible for transmitting and receiving EAR frames between the peer and authenticator. EAP has been run over a variety of lower layers including PPP, wired IEEE 802 LANs [see: IEEE802.1X], IEEE 802.11 wireless LANs [IEEE-802.11], UDP (L2TP [RFC2661] and IKEv2), and TCP.
[b] EAP layer. The EAP layer receives and transmits EAP packets via the lower layer, implements duplicate detection and retransmission, and delivers and receives EAP messages to and from the EAP peer and authenticator layers.
[c] EAP peer and authenticator layers. Based on the Code field, the EAP layer de-multiplexes incoming EAP packets to the EAR peer and authenticator layers. Typically, an EAP implementation on a given host will support either peer or authenticator functionality, but it is possible for a host to act as both an EAP peer and authenticator. In such an implementation both EAP peer and authenticator layers will be present.
[d] EAP method layers. EAP methods implement the authentication algorithms and receive and transmit EAP messages via the EAP peer and authenticator layers. Since fragmentation support is not provided by EAP itself this is the responsibility of EAP methods. Id.
The later cited reference sets forth the following definitions, which are cited herein for reference.
Authenticator:
The end of the link initiating EAP authentication. The term authenticator is used in [IEEE-802.1X], and has a similar meaning in this document.
Peer:
The end of the link that responds to the authenticator. In [IEEE-802.1X], this end is known as the Supplicant.
Backend Authentication Server:
A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X].
AAA:
Authentication, Authorization, and Accounting (AAA) protocols with EAP support include RADIUS and Diameter. In this document, the terms “AAA server” and “backend authentication server” are used interchangeably.
EAP server or Server:
The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in passthrough mode, the EAP server is located on the backend authentication server.
Successful Authentication:
In the context of this document, “successful authentication” is an exchange of EAP messages, as a result of which the authenticator decides to allow access by the peer, and the peer decides to use this access. The authenticator's decision typically involves both authentication and authorization aspects; the peer may successfully authenticate to the authenticator, but access may be denied by the authenticator due to policy reasons.
Master Session Key (MSK):
Keying material that is derived between the EAP peer and server and exported by the EAP method. The MSK is at least 64 octets in length. In existing implementations, a MA server acting as an EAP server transports the MSK to the authenticator.
Extended Master Session Key (EMSK):
Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet.
EAP Extension:
For reference, we refer to EAP Extensions for EAP Reauthentication Protocol (ERP), IETF Internet Draft, Aug. 24, 2007, of V. Narayanan, et al., seen at http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txt. The reference explains EAP Extensions for EAP Reauthentication Protocol as follows. “The extensible authentication protocol (EAP) is a generic framework for transport of methods that authenticate two parties; the authentication is either one-way or mutual. The primary purpose is network access control, and a key generating method is recommended to enforce access control. The EAP keying hierarchy defines two keys that are derived at the top level—the master session key (MSK) and the extended MSK (EMSK). In the most common deployment scenario, a peer and a server authenticate each other through a third party known as the authenticator. The authenticator or an entity controlled by the authenticator enforces access control. After successful authentication, the server transports the MSK to the authenticator; the authenticator and the peer derive transient session keys (TSK) using the MSK as the authentication key or a key derivation key and use the TSK for per-packet access enforcement.” Id. “When a peer moves from one authenticator to another, it is desirable to avoid full EAP authentication. The full EAP exchange with another run of the EAP method takes several round trips and significant time to complete, causing delays in handoff times. Some EAP methods specify the use of state from the initial authentication to optimize Re-authentications by reducing the computational overhead, but method-specific Re-authentication takes at least 2 roundtrips in most cases. It is also important to note that many methods do not offer support for Re-authentication. Thus, it is beneficial to have efficient Re-authentication support in LAP rather than in individual methods.” Id. “Key sharing across authenticators is sometimes used as a practical solution to lower handoff times. In that case, compromise of an authenticator results in compromise of EAP sessions established via other authenticators.” Id. “In conclusion, there is a need to design an efficient EAP Re-authentication mechanism that allows a fresh key to be established between the peer and an authenticator without having to execute the EAP method again.” Id. “This document specifies EAP Reauthentication Extensions (ERX) for efficient re-authentication using EAP. The EAP Reauthentication Protocol (ERP) based on ERX supports EAP method independent Re-authentication for a peer that has valid, unexpired key material from a previously performed EAP authentication. The protocol and the key hierarchy required for EAP Reauthentication is described in this document.” Id.